Implementation Notes

Issue #2 — DHCPv4 Option 82 Processing (RFC 3046) — 2026-06-14

Design Decisions

Decision Own SubOption type instead of exposing dhcproto RelayInfo directly

Ambiguity: Whether to use dhcproto's RelayInfo enum as the public API type.

Choice: Defined a simple SubOption { code: u8, data: Vec<u8> } struct for the relay agent's public surface.

Rationale: Decouples our API from dhcproto internals. If dhcproto changes its RelayInfo representation, only the conversion function needs updating.

Deviations

Deviation IPSec detection is a no-op placeholder

Spec said: Detect and skip DHCP packets protected by IPsec AH/ESP.

Implemented: is_ipsec_protected() always returns false.

Why: IPsec AH/ESP headers live at the IP layer. A DHCP relay operating on UDP payloads cannot inspect IP headers. The caller must perform this check at a lower layer and skip Option 82 processing before calling our functions.

Deviation RFC 3396 long option encoding delegated to dhcproto

Spec said: Support RFC 3396 long option encoding (option data > 255 bytes).

Implemented: dhcproto's encode_long_opt_bytes handles this automatically during serialization.

Why: No need to duplicate logic that dhcproto already provides. Verified via round-trip test.

Tradeoffs

Tradeoff insert() rejects existing Option 82 vs silently skipping

Alternatives: (A) Error on duplicate; (B) Silently skip insertion if already present.

Chose A: An existing Option 82 on a non-reforwarded packet is a protocol violation worth surfacing. The caller can check first if they want to skip silently.

Open Questions

Question VSS sub-options via Option 82

RFC 6607 VSS sub-options (151, 152) are encoded inside Option 82 alongside Circuit ID and Remote ID. The current insert() only handles the standard sub-options. VSS insertion will be added in Issue #6 — ensure it integrates with the existing Option 82 flow.